Computer networks, and in particular Wide Area Networks (WANs) such as the internet, provide opportunities for the misuse and abuse of communications. For example, two users (e.g., a human user and an enterprise server) communicating via the WAN may have their communications intercepted and/or altered. Also, it is possible for one user to misrepresent his, her, or its identity to another user.
Thus, there is a need for both privacy and authentication between users of the network communicating with one another. In other words, users should be able to rely on the fact that their transmissions will not be intercepted or altered, and that transmissions from someone purporting to be a particular user do in fact originate from that user.
In many secure communication applications, a seed is required in order to perform certain cryptographic operations such as encryption, decryption, authentication, etc. The seed may comprise, by way of example, a symmetric key or other secret shared by two or more entities.
One such application is in authentication tokens, such as the RSA SecurID authentication token available from RSA, The Security Division of EMC, of Bedford, Mass., U.S.A. The RSA SecurID authentication token is used to provide two-factor authentication. Authorized users are issued individually-registered tokens that generate single-use token codes, which change based on a time code algorithm. For example, a different token code may be generated every 60 seconds. In a given two-factor authentication session, the user is required to enter a personal identification number (PIN) plus the current token code from his or her authentication token. This information is supplied to an authentication entity. The authentication entity may be a server or other processing device equipped with RSA Authentication Manager software available from RSA Security Inc. The PIN and current token code may be transmitted to the authentication entity and if the PIN and current token code are determined to be valid, the user is granted access appropriate to his or her authorization level. Thus, the token codes are like temporary passwords that cannot be guessed by an attacker, with other than a negligible probability.
Referring to FIG. 1, there is illustrated an example of a system 100 that facilitates secure communication over a network. The system 100 comprises an authentication entity, for example, a server 105 for assisting in authenticating a user 110. To enable authentication, the user 110 can communicate with a user authentication device 120 for information used to authenticate the user 110. The user authentication device 120 may be a RSA SecurID token as discussed above. The user authentication device 120 may store a seed or secret that may be used to help authenticate the user 110. Typically, the seed may be information that only is available to the authentication device 120 and the server 105. For example, the seed can be used to help generate an authentication code for the user 110. The user authentication device 120 may also access dynamic data, which, for example, can be the current time, if implemented with a running clock. Additionally, in addition to a seed, the device 120 may receive a personally selected secret from the user 110 and generate a dynamic, non-predictable authentication code value in response to the secret received from the user 110, the seed, and the current time. Here, for example, a non-predictable authentication code value may be unpredictable to anyone who does not have access to the secret received from the user 110, the stored secret, and the algorithm that generates the authentication code value.
It will be appreciated that the user 110 may have access to a communications terminal 140 such as a personal computer, a personal digital assistant (PDA) or a similar device. During the authentication process the user may read a passcode from the user authentication device 120 and enter the code manually to the communications terminal 140. Alternatively, the user authentication device 120 may communicate with the communications terminal 140 to deliver the passcode thereto. The communications terminal 140 may communicate information to the server 105 via a communications channel 170. The communications channel 170 can be any method and/or interface that enables communication of information to the server 105 that may be required to authenticate the identity of the user 110. The communications terminal 140 can communicate information generated by the user 110, the device 120, or both, to the server 105 over the communications channel 170.
In order to authenticate the user, the server 105 performs algorithmic calculations for each user authentication attempt that is substantially identical to the algorithmic calculation performed by the user authentication device 120. The server 105 compares the authentication information received over communications channel 170 and the authentication information generated by the server 105 to determine whether there is a match. If there is a match, then the server 105 can authenticate the identity of the user 110.
Referring to FIGS. 2 and 3, there is illustrated an example of a user authentication device 200 suitable for issuing a passcode for authenticating a user. The device may be a RSA authentication token comprising a LCD display 210 for issuing a passcode to a user. The device may also contain a plug portion for plugging into a USB port. This facilitates communication between the communications terminal, for example, a computer, and the device. The display 210 in FIG. 3 is illustrated in a non-energized non-operational state comprising six passcode numerals (888 888) that may represent a passcode. The display also comprises three peripheral numerals (1, 2, 3) and a diamond character (0) located on the right side periphery thereof. Additionally, the display comprises countdown bars on the left side periphery thereof. The countdown bars may illustrate the time remaining before a new passcode is issued and displayed on the display. For example, a new passcode may be issued and displayed every sixty seconds and one countdown bar may disappear every ten seconds to illustrate the time remaining before a new passcode is displayed.
It will be appreciated that when the token as described above is created the unique seed for the token is placed into a token record. The token record may then be loaded into the authentication entity, for example, the server to allow the token to be used in an authentication event.
Accordingly, a mechanism or technique is required for delivering (e.g., securely delivering) the token records from a token manufacturer to an end customer. If the information in a token record is revealed to an attacker, there is a risk that the attacker may be able to use such information to the attacker's advantage. In particular, a mechanism or technique is required for distributing the tokens through indirect channels such as a value added reseller or some other third party. Typically, these indirect distributors maintain an inventory of tokens in stock such that the end customers can buy tokens as needed. Indirect distribution adds a layer of security complexity to token record distribution since the end customer may be unknown to the token manufacturer at the time that the tokens are programmed and the token records are produced by the manufacturer. Furthermore, when leveraging indirect distribution, the personnel and processes of the indirect partner are outside the control of the token manufacturer and therefore the manufacturer cannot always assume that the indirect partner is totally secure.
In the past, storage media such as CD-ROMs have been used to distribute token records with token shipments.
Other techniques have also been used in the past to deliver token records.